System and Method for Caching of Data in a Computer System

ABSTRACT

A system and method are presented for using a plurality of data caches to increase the efficiency of a computing system in an e-commerce environment. Separate caches with distinct time-to-live values are created, one each for customer information, customer cart contents, and product pricing data. Product pricing is pre-analyzed using a pricing data engine that calculates multiple potential prices for a single item that is then stored in the product pricing data cache. This data can then be used in a variety of contexts to determine different pricing for the same product without requiring another request for product data from the pricing data engine. When a product is viewed during catalog browsing, all information needed to determine pricing for that particular user might be accessible from the data caches for fast processing.

RELATED APPLICATIONS

The present application is a continuation of U.S. Serial No. 17/519,099,filed on Nov. 4, 2021 (the ‘099 Application). The ‘099 Application is acontinuation of U.S. Serial No. 16/693,641, filed on Nov. 25, 2019 (nowU.S. Patent No. 11,182,817), which itself is a continuation of U.S.Serial No. 15/808,948, filed on Nov. 10, 2017 (now U.S. Patent No.10,504,131) (the ‘948 Application). The ‘948 Application claimed thebenefit of U.S. Provisional Application No. 62/516,332, filed on Jun. 6,2017. All of these priority applications are hereby incorporated byreference in their entireties.

FIELD OF THE INVENTION

The invention relates to caching techniques for providing the fastresponse times required for high-capacity, computer data throughput. Inparticular, the invention relates to the early fetching and caching ofdata details in order to provide responsive analysis in an e-commerceenvironment.

SUMMARY

When a user is browsing an e-commerce website for a product, the pricefor that product is dynamically determined and presented to the user(before the item is added to the shopping cart). A pricing engineprovides this capacity by calculating the price for a product based onpromotions (“offers”) defined in an offer repository. Offers areexamined and determined to be relevant to a currently-viewed productbased on information acquired about the user or based on productscurrently in the user’s shopping cart. Relevant offers are then used toalter the price presented to the customer on the website for thatproduct.

Data relevant to these calculations are maintained in separate caches toimprove processing speeds. Repeated data access requests are avoided byproviding separate caching resources for different data requests. Eachcache can provide a different time-to-live period based on the type ofdata maintained by the cache. External caches can be used to allowshared cache access to multiple computing instances that provide thedynamic pricing process.

Dynamic pricing is made possible during catalog browsing by evaluatingoffers in an offer repository to determine customer data that isrelevant to potential promotions. Relevant customer data is retrievedbefore product browsing and maintained in a cache for extremely fastdata retrieval during product browsing (effectively eliminating the needfor standard database queries during product browsing). When productsare added to the cart, promotions relevant to the cart contents are alsoretrieved and maintained in cache. When a product is viewed duringcatalog browsing, promotions relating to that product can be retrievedfrom the offer repository. All information needed to determineeligibility for the promotion is maintained in the cache for easyretrieval. Applicable promotions can then be used to calculate thedynamic price by the pricing engine, and the dynamic price can bedisplayed to the user. In one embodiment, a separate pricing data engineis used to calculate all possible prices for a product given theavailable promotions. This separate engine then generates a list of allpossible prices for relevant products. When this data is stored in cachememory, great efficiencies are generated in the calculation of dynamicprices for a particular combination of a customer and items beingpurchased.

The promotions may be of two types. The first type of promotion isconsidered a personalized dynamic price. This type of promotion providesdiscounts based on information known about the user, such as the user’sprior shopping history or their customer profile. For example, discountsmay be provided to only a subset of users based on a characterization ofthat user by the e-commerce site (such as discounts that are providedonly to users that have been identified as a “student” or a “parent”).The personalized pricing engine obtains information about the user,caches this information, identifies a product being viewed, determinesif cached information qualifies the user for a promotion on the viewedproduct and, if so, dynamically adjusts the price displayed to the user.

The second type of promotion is price bundling, and provides discountsbased on items found in the cart of the user. If the user has placed aparticular item in their cart, related products may be discounted as aresult. The pricing engine identifies these types of offers, verifiesthat the user has the appropriate “triggering” item or items in theircart based on previously cached data, and then determines theappropriate price for display to the user when browsing that item. Thesystem can also determine if the discounted item is in the cart, andprovide notification to a user when viewing the triggering item that theitem already in the cart will be discounted if they purchase thetriggering item.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic view of a system implementing one embodiment ofthe present invention.

FIG. 2 is a flow chart showing a process of personalized dynamic pricingusing improved caching.

FIG. 3 is a flow chart showing a process of product bundling dynamicpricing using improved caching.

FIG. 4 is a screen shot showing product bundling reducing the price ofan item being viewed.

FIG. 5 is a screen shot showing product bundling reducing the price ofan item in the user’s cart.

FIG. 6 is a schematic view of a second embodiment system operating aplurality of separate caches to implement the present invention.

FIG. 7 is a schematic view of a third embodiment system in whichmultiple instances of pricing aggregators communicate with a singlepricing data engine, with each instance having a separate cache.

FIG. 8 is a schematic view of a fourth embodiment in which cachememories are shared between multiple instances of pricing aggregators.

DETAILED DESCRIPTION Overview

FIG. 1 shows one embodiment of a system 100 for operating an e-commercewebsite that is accessible by a user device 110. In system 100, the userdevice 110 may be a computer operating a web browser, or a tablet orsmart phone operating either a browser or an e-commerce app. The userdevice 110 communicates with one or more servers that operate thee-commerce operations of a retailer. In FIG. 1 , the servers operateproduct catalog programming 120 as well as checkout processingprogramming 130. These two different programming elements 120, 130 mightoperate on a single server. Alternatively, a group of servers mayjointly provide both catalog programming 120 and check out processingprogramming 130 for the e-commerce site. In a further embodiment, afirst server (or group of servers) operates the product catalogprogramming 120, while a second server (or group of servers) operatesthe checkout processing programming 130.

The product catalog programming 120 provides the catalog of availableproducts to the user device 110 for browsing. In this context, browsingmeans reviewing one or more products available for purchase through thee-commerce operation before the item is selected for purchase or placedinto a shopping cart basket for later purchase. The products may bedisplayed in separate web pages (or separate screens on a dedicatedshopping app), or multiple products may be displayed on the same page orscreen. In each case, the catalog programming 120 will provide imagesand/or descriptions for the products being browsed, will provide pricinginformation for that product, and will provide an ability for thecustomer to purchase the product by placing the product into a virtual“shopping cart.” In the embodiment of FIG. 1 , the product catalogprogramming can provide a dynamic price 122 to the user device duringthis display of the product catalog.

The product catalog programming 120 obtains product data, includingproduct descriptions and images, from a product database 142. Theproduct database 142 also contains the base pricing information 143 forthe products. The catalog programming 120 uses its internal programmingto format and present the product information and price in a pleasingmanner to the user device 110. In the prior art, the product catalogprogramming 120 would simply provide the static, base pricinginformation 143 to the user during product presentation of the catalog.The base pricing 143 in the database 142 can be updated from time totime to reflect product price changes, sales events, and other permanentand temporary price changes to the product. But the resulting price 143that was displayed in the prior art is considered “static” because itdoes not change based on the identity or shopping behavior of the user.In contrast, the embodiment shown in FIG. 1 presents a dynamic price 122during the review of the product catalog because of the presence of thepricing engine 140, which is described in more detail below.

When a user has decided to purchase one or more products, theidentifiers 126 for the selected products are shared with the checkoutprocessing programming 130 (such as by indicating that these identifiers126 are in the customer’s virtual shopping cart). This programming 130can also use a customer identifier 124 for the customer to provide apersonalized checkout experience. Using the customer identifier 124, thecheckout programming 130 can access information about the customer froma customer database 134. Accessing customer data 134 allows the checkoutprogramming 130 to simplify the checkout process. Additionally, thecheckout programming 130 may access a promotions database 136 todetermine whether the items in the shopping cart are covered by anypromotions, and a loyalty/stored value database 138 to determine whetherthe customer has access to any rewards in a loyalty program or othertypes of stored value that can be applied to the purchase transaction.

In accessing these data items 134, 136, 138, the checkout processingprogramming 130 gains the ability to alter the base pricing 143 for aproduct. In other words, the checkout processing programming 130 cancreate a calculated sale price 132 on one or more items and present thatto the user. This calculated sale price 132 is considered different thanthe dynamic price 122, as the calculated sales price is determinedduring the checkout process while the dynamic price 122 is determinedwhile simply browsing the product catalog. The processing power used bythe checkout processing programming 130 to query the appropriatedatabases 134, 136, 138 and to calculate an adjusted sale price 132 fora product is significant. The time required for this processing isacceptable during checkout processing 130 because there aresignificantly fewer transactions handled by this processing 130 whencompared with the product catalog processing 120. For example, theproduct catalog programming 120 in some large e-commerce sites handlemore than 10,000 transactions per second. In contrast, the checkoutprocessing programming 120 on the same site might handle fewer than 100transactions per second. Therefore, the product catalog programming 120of the prior art, which fails to use the pricing engine 140 shown inFIG. 1 , is not able to generate and present to the user device 110anything other than the static base price 143 for a product.

Pricing Engine 140 and Methods 200, 300

In practice, the pricing engine 140 is a computing device having aprocessor, random access memory, a high-speed data cache 141, and datacommunications to the product catalog programming 120 and various datasources 142-150. The product catalog programming 120 is similarly acomputing device having a processor, random access memory, and datacommunications ability. This element 120 is described as the productcatalog “programming” because the element provides the capability ofproviding catalog pages to end users through its programming. In effect,both elements are instances of computing devices performing specializedprogramming that communicate with each other. These computing devicesmay be operating on the same physical device, perhaps using multipleprocessors to perform different processes simultaneously. In otherembodiments, these elements 120, 140 operate on separate physicalmachinery. As is explained in more detail below, the computing devicesrely on caching memories to improve the efficiency of a process that wasnot capable of operation at high volumes prior to the introduction ofthese efficiencies.

The pricing engine 140 provides a dynamic price 122 to the productcatalog programming 120. This allows the programming 120 to present adynamic price 122 to the user device during the display of the productcatalog. The pricing engine 140 may take the form of a speciallyprogrammed computer that presents the dynamic price to the server orservers operating the product catalog programming 120, or may take theform of a subroutine or other process running on the same server(s) asthe product catalog programming 120. Alternatively, the pricing engine140 can be considered merely a constituent part of the product catalogprogramming 120.

Regardless of its physical implementation, the pricing engine 140 hasaccess to a data cache 141 to maintain local data. Data can be retrievedfrom external business databases and stored in the data cache 141 forfast analysis and manipulation by the pricing engine 140. By definition,the cache 141 is separate from the external databases and allows forfaster data access than these external databases.

In the preferred embodiment, the pricing engine adjusts the base price143 into the dynamic price 122 appropriate for the current user session,using two slightly different methods. These two methods are thepersonalized dynamic price method 200 shown in FIG. 2 , and the productbundling dynamic price method 300 shown in FIG. 3 . While these areshown in the figures as two separate methods 200, 300, at least oneembodiment implements both methods simultaneous to create a singledynamic price 122. These methods are described immediately below, andare described in the context of system 100 shown in FIG. 1 .

The personalized dynamic pricing method 200 shown in FIG. 2 is designedto create a dynamic price 122 based on the identity of the user usingthe user device 110. The method 200 starts with the step 210 ofidentifying the user. The user can be identified by any means known inthe prior art. For instance, a user may log into the e-commerce system100 and begin a user “session” with the system 100. Each communicationwithin the session will include an identifier (such as a session ID),which allows the system 100 to know the user associated with allcommunications to and from the user device 110. Even without requiringuser login, a cookie or other data element associated with a single usercan be stored on the user device 110 and communicated to the system 100to identify the user. Alternatively, the user device 110 could utilizean app specialized for interaction with the e-commerce system 100, andthe app could automatically identify the user.

Once the user is identified, the pricing engine 140 will locate any datathat is associated with the identified user that may impact the dynamicprice 122 for a product. This is accomplished by examining a “live eventfeed” for the user in step 220. The type of data that may impact thisprice 122 can vary widely depending on the desires of the entityoperating the e-commerce system 100. In one embodiment, users areidentified by segments or categories, and discounts are directed to onlyone or more segments of a retailer’s customers. For example, thee-commerce site might be selling school supplies, and a discount may begiven to all college-aged users on certain school supplies. Such adiscount might be more specific, and be limited only to users known tobe attending colleges, or parents of children attending college. Inthese cases, the pricing engine 140 would need to access a customerdatabase 144, which may be the same as, or similar to, the customerdatabase 134 accessed by the checkout processing programming 130. Thecustomer database 144 may contain segmentations/characterizations ofcustomers that have been previously established through databaseanalysis or prior user confirmation. These characterizations may be, forexample, “college student,” “parent,” “professional,” “home-schoolingparent,” “athlete,” “avid reader,” “video game player,” “trendsetter,”or “sale-shopper.” Of course, these characterizations are only relevantto the pricing engine 140 if the system 100 has established specialpricing for individuals based on those characterizations. In the methodshown in FIG. 2 , identifying these characteristics takes place in step230.

Alternatively, the system 100 may establish special pricing forindividuals based on their prior purchases. For instance, a person thathas purchased a garden tractor may be eligible for discounts on tractoraccessories for the next six months, or an individual that purchased aportable computer may be eligible for special pricing on printers. Tohandle these discounts, the method 200 will examine (at step 232) thecustomer database 144 (or some other similar database that containspurchase history data) and determine the relevant past purchases for thecurrent customer.

Alternatively, or in addition, the method 200 will examine the status ofthe current user in the e-commerce system’s loyalty program in step 234.The loyalty program may assign program levels (such as silver, gold, orplatinum status) to customers, and may offer rewards, discounts, orspecial pricing for loyal customers based on past activities. Thebenefits earned in the loyalty program may be stored in the customerdatabase 144 (or in a similar database), and can be accessed in thisstep 234 to present the user with a dynamic price 122 that reflectsthose benefits.

Note that not all characterizations for a customer (identified in step230) will impact the pricing 122 for products maintained by thee-commerce system 100. Similarly, not all past purchases will berelevant for discounts, and not all loyalty benefits will impact adynamic price 122 to be displayed. The pricing engine 140 must knowwhich data is relevant given the promotions and discounts currentlyavailable through the e-commerce system 100. In one embodiment, allcurrently available promotions are stored in an offer repository 148.The offer repository 148 is a database (or a portion of a database) thatcontains data about discounts and promotions that impact the pricing ofa product available through the system 100. Each offer will containrules defining the amount of the discount or a technique to calculatethe change in price (such as “buy one, get the next at 50% off”). Theoffer will specify which products are to be discounted, and the criteriathat must be met before the offer is applicable. For example, the offermay only apply to customers that have been identified as collegestudents. Alternatively, the offer may only be available if a user haspreviously purchased a Sony television, or is a “gold status” member orbetter in the loyalty program. These criteria are often referred to as“prerequisites” or “triggers” for the offers, as the offers are notavailable until the criteria are met. If the pricing engine 140 is awareof all the triggers in the offer repository 148, the pricing engine candevelop a list of the data that are relevant to trigger these offers.Information about a customer that does not trigger an offer in the offerrepository 148 is not relevant to the pricing engine 140. Thus, in oneembodiment, steps 230, 232, and 234 identify only relevantcharacterizations, past purchases, and loyalty program information thatconstitute a trigger for an active offer in the repository. The offersin the repository 148 change over time, so the list of applicabletriggers will also change over time.

Because of the time required to create the dynamic price 122 during theuser’s catalog browsing session (before the checkout process), thepricing engine 140 must perform its processing as quickly as possible.In the preferred embodiment, the pricing engine increases itsperformance by carefully caching the results of steps 230, 232, 234 intodata cache 141. This allows the pricing engine 140 to reuse the resultsof its data queries and analysis without re-querying the externaldatabases 144 every time the customer views new products in the productdatabase 142.

At step 240, the process identifies the item that is currently beingviewed by the user device 110. The pricing engine 140 obtains the baseprice information 143 and other relevant information from the productdatabase 142. The pricing engine 140 will then identify potentialpromotions by requesting a list of offers from the offer repository 148that apply to the selected products (step 250). In the preferredembodiment, product information and promotion data are also cached bythe pricing engine 140 so that physical requests for data from theproduct database 142 and offer repository 148 can be minimized.

Next, the pricing engine 140 will apply the cached data from steps 230,232, and 234 to identify which of these potential promotions areactually applicable at step 260. For example, step 250 may identify apotential promotion for a selected product that requires that thecustomer be at the “platinum” level in the loyalty program. However,step 234 cached that the customer is only at the “gold” level, so step260 will not identify this promotion as applicable.

When applicable promotions are identified in step 260, step 270 willcalculate the dynamic price 122 for those products based on thoseapplicable promotions. If multiple promotions apply to an individualproduct, then step 270 will determine which promotion(s) should beapplied. For instance, business rules embodied in step 270 may indicatethat the promotions should be applied to create the lowest dynamic price122, or may indicate that certain promotions should always be appliedinstead of other promotions. The business rules implemented in step 270can be varied as desired. The calculated dynamic price from step 270 isthen used to alter the price presented by the product catalogprogramming 120 to the user device 110 in step 280. In this way, theuser of user device 110 receives the dynamic price of the product duringnormal browsing of the product catalog, and does not need to wait untilcheckout to see all the relevant discounts.

In the preferred embodiment, the dynamic price presented in step 280 isthe only price presented and is presented “inline” along with the restof the product description. This means, for example, that the dynamicprice is not presented as a “pop-up” in a separate window or overlayover the product display. Furthermore, the user is not required to clickon a link, or to place an item in a cart, before the dynamic price isdisplayed in step 280. After step 280 is complete, the user may elect toview additional or different items. In this case, the method 200 returnsto step 240, and the previously cached data from steps 230, 232, and234, and previously cached product and promotional information fromsteps 240 and 250 are reused to create the dynamic price 122 for the newitems. Alternatively, the method can end at step 290 after the dynamicprice is displayed.

FIG. 3 discloses a method 300 for product-bundling dynamic pricing. Theproduct-bundling dynamic price method 300 is designed to show dynamicpricing that relates to product “bundling” promotions. In other words,certain promotions may require that two items be purchased together. Inthis case, if a user has one of the two items in their shopping cart,this method 300 will identify the situation and alter the dynamic price122 for one or both items. The first step 310 in this method isoptional, and it is to initiate the personalized dynamic pricing method200. In other words, the two methods 200, 300 should not be consideredmutually exclusive alternatives for calculating a dynamic price 122, butas complementary processes that can operate together.

In step 320, the process 300 identifies those products that the usercurrently has in her shopping cart. In FIG. 1 , the cart contents arefiguratively shown as a separate database 146 accessed by the pricingengine 140. In an actual implementation, it is unlikely that thecontents of user shopping carts will constitute a separate database. Thepresence of an item in the cart indicates an intention (or at least adesire) for the user to purchase that item. In some environments, thecontents of a user’s cart can be saved in cache 141. At step 330, themethod then identifies and caches any promotions that involve productscurrently in the shopping cart. Note that the items in the cart can bethe discounted item in the promotion, or can be the “triggering” itemthat triggers a promotion on another item, or both. In either case, step330 will identify and cache that promotion. In some embodiments, thepromotions identified in step 330 will require an evaluation of customerdata 144 in a manner similar to that performed in method 200. Forinstance, the promotion may indicate that purchases of a portablecomputer may qualify for a discount on a printer, but only if thecustomer has attained a “platinum” level in the loyalty program. If thiscustomer information was previously cached in step 234, it would be asimple matter to examine this cached data when determining thepromotions for step 330.

At step 340, the user has indicated a desire to view information aboutparticular products. Once those items are identified, step 350 willdetermine whether there are any cached promotions for which the vieweditems constitute a trigger for a discount on the item currently in thecart. At the same time, step 352 will determine whether there are anycached promotions that discount the viewed items based on a trigger itemfound in the user’s cart. If either step 350 or 352 identify one or morepromotions, step 360 will calculate a new dynamic price based on thesepromotions.

In some embodiments, the offers in the offer repository 148 arecontingent on fulfillment information, inventory data, and/or sales datarelated to those items being discounted. For example, a promotion mayapply only if the two items being bundled are being shipped from thesame distribution center. Alternatively, the promotion may apply only ifthe item being promoted has sold poorly during the last month. Poorsales may be determined, for example, relative to related products, ormay be determined by examining the sales of an overall product category.In yet another example, a promotion may be discontinued if the inventoryfor the discounted product is reduced below a certain threshold value.Information about fulfillment, inventory, and/or sales data can bestored in one or more separate databases 150 accessed by the pricingengine 140. Step 370 is responsible for determining that anycriteria/triggers related to this type of data are met before thedynamic price 122 is shown to the user. Step 370 is shown as a separatestep in FIG. 3 , but other embodiments would examine these types oftriggers along with other triggers in steps 330. In this way, the cachedpromotions from 330 would reflect the application of any fulfillment,inventory, and/or sales data triggers. Note that these types offulfillment/inventory/sales triggers can also be applied to thepromotions applied in the dynamic pricing method 200.

At step 380, the dynamic price for the items involved can be updated andpresented to the customer. As was the case in step 280, these prices areintegrated into the same screen that presents the product informationwhen the customer is browsing the catalog of products presented by thee-commerce system 100. However, the presentation of a bundling dynamicprice is different in that the price provided requires the purchase ofanother item. This difference is shown in the presentation screensconceptually presented in FIGS. 4 and 5 .

FIG. 4 shows a presentation screen 400 created by method 300 when step352 identified a promotion that alters the dynamic price of a vieweditem because a trigger item (the “second-product”) for the promotion isfound in the user’s shopping cart. As explained above, the dynamic price122 is presented in the product information screen. In FIG. 4 , thisscreen 400 contains a product image 410 and a product description 420.The dynamic price 430 is presented along with an explanation of how andwhy the relevant promotion is altering the base price for this product.In this case, the dynamic price 430 represents a $3.00 discount becausea second-product is already in the user’s cart. The second-product, inthis case, is the triggering item for a promotion on the product beingdisplayed. The explanation explains that this discount will apply onlyif the second-product is also purchased at the same time.

Similarly, FIG. 5 shows a presentation screen 500 for the same product.In this case, step 350 identified a promotion where the viewed productis a trigger product and the product in the shopping cart (the“third-product”) is the product being discounted. The price displayed530 on this screen 500 is not directly discounted, but the explanationindicates that a significant discount will be provided to the customerfor the third-product already in the shopping cart if the user were toalso purchase the displayed product. Note that this discount is onlyavailable if the user purchases this trigger item. This means that ifthe user were viewing a different item that was not a trigger item, nodiscount would be presented relating to the third-product in theshopping cart.

Alternative Embodiment 600

FIG. 6 shows an alternative embodiment 600 where the role of the pricingengine 140 is divided into a pricing aggregator 610 and a pricing dataengine 620. The pricing aggregator 610 is responsible for receiving therequest for a dynamic price 122 from the product catalog programming120. This request identifies both the SKU number (or other product code)for the product that requires pricing information as well as auser-token that uniquely identifies the user that is requesting theproduct price. The contents of this request are shown in FIG. 6 withinthe dashed line box next to the dashed downward arrow between theproduct catalog programming 120 and the pricing aggregator 610. FIG. 6uses these dashed arrows and boxes to identify data that is movingbetween the schematic elements shown in the Figure. For example, thedashed upward arrow between the pricing aggregator 610 and the productcatalog programming 120 indicates that the pricing aggregator 610 isresponsible for providing the dynamic price 122 to the product catalogprogramming 120. When the product catalog programming 120 receives thisdynamic price 122, it creates a web page (or other user interface)incorporating this dynamic price 122 for the user device 110 in the samemanner as described above in connection with FIG. 1 .

The pricing aggregator 610 is shown in FIG. 6 with three highspeedmemory caches, namely cache-1 612, cache-2 614, and cache-3 616. Thesethree caches 612, 614, 616 can be implemented on three separate,physical memory devices, or they can be implemented on a single memorydevice and just be maintained separately on that device.

The pricing aggregator 610 receives information about a customer statusand segmentation from the customer database 144. To obtain thisinformation, the pricing aggregator 610 submits the user-token (or dataderived from the user-token) received from the product catalogprogramming 120 to the customer database 144. The pricing aggregator 610receives the customer status and segmentation information (such as the“gold status” of the customer in the retailer’s rewards program and the“college student” segmentation information) and stores this in cache-1612. Since the type of information stored in cache-1 is unlikely tochange very frequently (the status or segmentation information for acustomer will change very rarely), the information in cache-1 612 can bestored for a long time without refresh. In one embodiment, thetime-to-live (“TTL”) for this cache-1 is measured in hours (one or morehours), as is shown in FIG. 6 . This means that once the pricingaggregator 610 receives information about this customer from database144, it will be able to read this information out of cache-1 for the TTLperiod without submitting another request to the customer data source144. This caching greatly increases the efficiency of the pricingaggregator 610. It is generally preferred that the TTL for cache-1 isgreater than one hour, so as to limit as many unnecessary calls to thecustomer data source 144 without significant risk of missing a change ofcustomer status or segmentation.

The pricing aggregator 610 also receives information about the user’scart contents from data source 146. The cart contents database 146tracks those items that a user has in her cart, and is updated from aseparate shopping engine process 640 (not shown in FIG. 1 ) every timethe user adds or removes an item from their shopping cart. The pricingaggregator 610 requests this information by submitting useridentification data to the cart contents database 146, and the database146 responds by providing all the product identifiers (such as the SKUnumbers) for the products in that user’s shopping cart. The pricingaggregator 610 saves the content of the user’s cart in cache-2 614. Thismeans that if the user requests the price of a second productimmediately after requesting the price of a first product, the pricingaggregator 610 does not need to request the content of the user’s cartfrom database 146, but can instead read this data from cache-2 614. Inorder to be useful, the time-to-live value from this cache-2 614 must belong enough to allow for multiple price requests, but it cannot be solong as to miss a user’s transaction with the shopping engine 640. Inone embodiment, the TTL for cache-2 614 is measured in seconds (one tosixty seconds). Although this time-to-live can vary between embodiments,it is generally preferred that the TTL for cache-2 614 be less than oneminute so that changes to the cart content are not missed.

The pricing aggregator 610 receives a third type of information from thepricing data engine 620. The pricing data engine 620 is responsible forinforming the pricing aggregator 610 of every possible price that isrelevant for the determination of the dynamic price 122. In other words,the pricing data must indicate all possible prices for the SKU receivedfrom the product catalog 120, such as one price for “gold status”customers, another price for “elite status” customers, and a third pricefor “college student” segment customers. As explained above, the dynamicprice 122 may also take into consideration the impact of the productscurrently found in the user’s shopping cart. In order to provide thisinformation, the pricing aggregator 610 must include both the itemidentified by the product catalog programming 120, and also all theitems currently found in the customer’s cart. In return, the pricingdata engine 620 will inform the pricing aggregator of every possibleprice for all of the items (both the requested item and the items in thecart), for all possible customer statuses and segments, and for allcombination of products among those included in the request.

For example, a user may have a camera (product ID 1001) and a case(product ID 1002) for that camera in her cart, and the product catalogprogramming may request the dynamic price for a related camera lens(product ID 1003). As explained above, the pricing aggregator 610 learnsthe content of the user’s cart by accessing cache-2 614 or requestingthat information from the cart contents database 146. The pricingaggregator 610 will include all three product identifiers (1001, 1002,and 1003) in the price request submitted to the pricing data engine 620.The pricing data engine 620 will return pricing information for each ofthese items reflecting all possible discounts for a user status orsegment, and all possible discounts for bundled product discounts. Inthis simplified example, the data might be as follows:

Product ID Cust Class Cust Segment Purchased With Price 1001 500 1001Elite 480 1001 College Student 490 1001 Elite College Student 460 100275 1002 1001 25 1002 Elite 1001 0 1002 2015 25 1003 200 1003 1001 and1002 100

In this chart, the first column contains the product ID, and the lastcolumn indicates the price for that product. The intermediate columnscontain the prerequisites that must be met for that price to apply tothat product. If these intermediate columns are blank, then that rowcontains the base price 143 for that product. According to thisinformation, the camera (product ID 1001) is normally priced at $500,but is discounted for elite members of the rewards program down to $480,and is discounted for known college students down to $490. Elite collegestudents can purchase the camera for $460. The camera case (product ID1002) is normally priced at $75, but can be purchased for $25 ifpurchased with the camera (product ID 1001). This same case is free ifpurchased by elite members along with the camera. The requested item(the item being viewed by the customer) is the camera lens (product ID1003), and this information indicates that the price of the lens is$200, but the lens can be purchased for $100 if purchased along withitems 1001 and 1002.

Note that pricing information returned by the pricing data engine 620also indicates that the camera case (product ID 1002) can also bepurchased for $25 if purchased with item ID 2015. This item is not foundin the user’s cart, and therefore was not identified in the pricerequest from the pricing aggregator 610. Nonetheless, the pricing dataengine 620 will include this information in the pricing data returned tothe pricing aggregator 610 as it may be useful for the next pricingrequest received by the pricing aggregator 610. In other words, thepricing data engine 620 provides all possible prices for all the itemslisted in the price request. This means that the pricing data engine 620has no responsibility for determining which of these prices is relevantin the current context; it needs only to provide all known possibleprices for the items contained in the price request from the priceaggregator 610. It is then up to the pricing aggregator 610 to determinewhich of these prices is relevant for the current user.

The pricing data received from the pricing data engine 620 is stored bythe pricing aggregator 610 in cache-3 616. The time-to-live of the datain this cache-3 616 is longer than the TTL in cache-2 614 (as it is lesslikely to change), but is shorter than the TTL in cache-1 612 (as is itsubject to more frequent changes than the customer status andsegmentation). In the embodiment shown in FIG. 6 , the TTL for cache-3is measured in minutes (between one and sixty minutes). This means thatproduct pricing information obtained from the pricing data engine 620can be obtained from the cache-3 616 for the TTL period after it wasreceived from the pricing data engine 620. In most circumstances, arelatively small percentage of the products within a retailer’s productcatalog make up a large percentage of the products being reviewed andpurchased by a customer. During extremely busy times for an e-commerceretailers, a large percentage of its customers are focusing in on saleitems. Pricing requests for these sale items could overwhelm the pricingdata engine 620 if not for the presence of the cache-3 616. Thus, eventhough the cache-3 616 stores the pricing information for minutes, thisis enough time to handle thousands of requests for pricing information.

The pricing aggregator 610 examines the pricing data received from thepricing data engine 620 and compares the pricing prerequisites in thatpricing data with both the user information received from customer data144 and the cart content information received from the cart contentsdata source 146. From this information, the pricing aggregator 610 candetermine the best price for the product based on this customer’s uniquestatus and segmentation information. In addition, the pricing aggregator610 can determine whether any of the items in the user’s cart can bebundled with this product in order to reduce the price of the product.Finally, the pricing aggregator can determine whether any of theproducts already in the user’s cart will have their prices reduced bythe purchase of the currently reviewed product. This information is thenpresented back to the product catalog programming 120 in the form of thedynamic price 122.

The pricing data engine 620 acquires information about the availableprices for the requested products from the product database 142, theoffer repository 148, and the fulfillment/inventory/sale data source150. In one embodiment, each of these separate data sources 142, 148,and 150 are capable of monitoring themselves and then push any detecteddata changes to an external processor. To handle the receipt of thispush data, and to avoid overwhelming the capabilities of the pricingdata engine 620, a data collector 630 is used. This data collector 630receives these push notifications and then updates an intermediatedatabase that stores the current status of each of these data items.Although FIG. 6 shows that the data collector and database within thesame schematic element 630, the data collector and intermediate databasecould also be viewed as separate elements in the overall system 600.

The pricing data engine 620 requests information about products andoffers from the data collector 630. Product information received fromthe data collector 630, including a product’s base price, is cached bythe pricing data engine 620 in its product cache 622. The time-to-liveof this cache 622 in the embodiment shown in FIG. 6 is also measured inminutes. In one embodiment, the TTL for cache 622 is less than thecache-3 616, which means when the pricing data in the cache-3 616 goesstale, it will receive product data from the pricing data engine 620that is no older than the TTL of cache 622. This helps to ensure thatthe data in cache-3 616 related to product data such as the base priceof a product is never for too long of a period removed from the actualproduct database 142. Offer related information is also cached by thepricing data engine 620, this time in an offer cache 624 that has a TTLmeasured in minutes as well. The TTL for cache 624 can be longer thanthe TTL for cache 622 because offers are subject to less frequentchanges and less urgent changes than those made to the product database142. For example, the TTL for cache 624 may be 2-3 times longer than theTTL for cache 622. As described above, some offers may depend on currentinventory levels, prior sales data concerning the product, orfulfillment information such as ship-from locations. This data 150 canbe used by the pricing data engine 620 to determine relevant offers forvarious products, and can be temporarily stored in the offer cache 624.

Although it is not shown in FIG. 6 , in some embodiments the pricingaggregator may also be responsible for determining fulfillment/shippingprices for products and groups of products. Some products may havespecial shipping costs or processes, or in other cases certain customersmay be eligible for discounted shipping. One may also provide a shippingdiscount when all products within a promotional bundle are purchasedtogether. This type of fulfillment processing can be handled by thepricing aggregator 610 in much the same way as the dynamic pricing ishandled. In fact, fulfillment pricing can be incorporated into thedynamic price 122 that is returned to the product catalog programming.In particular, fulfillment offers for the relevant items can berequested from the pricing data engine and stored with the productpricing information in cache-3 616. Alternatively, a fulfillment engine(not shown in FIG. 6 ) can be provided that provides the necessaryfulfillment data to the pricing aggregator 610. The pricing aggregatorcan request fulfillment data for all relevant products from thefulfillment engine, and then store data in a fourth cache (not shown).

FIG. 7 shows an alternative configuration 700 where multiple instancesof the product catalog programming 120 interact with multiple instancesof the pricing aggregator 610. These different instances may be onseparate physical devices, or may be operating in parallel on a singlecomputing device. The instances may even be operating on devices thatare physically remote from one another. In the embodiment shown in FIG.7 , three instances of the product catalog programming 120 serve webpages (or other user interfaces) to end user devices 110. The elements120 shown in FIG. 7 are computing devices operating the programming 120independently. Each instance 120 needs to communicate with the pricingaggregator 610, and in FIG. 7 there are three instances of the pricingaggregator 610. In this embodiment, any of the product catalogprogramming instances 120 can communicate with any of the pricingaggregators 610. Each of the pricing aggregators 610, in turn, need tocommunicate with the pricing data engine 620. In the embodiment shown inFIG. 7 , only a single pricing data engine 620 is provided, and allinstances of the pricing aggregator 610 communicate with the samepricing data engine 620.

In this type of embodiment, it is especially important not to OVERburdenthe pricing data engine 620, or else the entire system 700 can bog downdue to the bottleneck of communicating with the pricing data engine 620.As a result, efficient use of cache-3 616 can reduce calls to thepricing data engine 620 and increase the efficiency of the overallsystem 700. As shown in FIG. 7 , each pricing aggregator 610 in thisembodiment has its own, separate cache-3 616 to cache data that itreceives from the pricing data engine 620. While this improves theefficiency of the system 700, it fails to take advantage of all of thedeterminations and transmissions made by the pricing data engine 620.Data sent to one pricing aggregator 610 is not made available to anyother pricing aggregator 610.

FIG. 8 shows a partial embodiment of another system 800 that overcomesthis issue. FIG. 8 shows only the interaction of the pricing aggregatorinstances 610 with their primary data sources 144, 146, and 620. In thiscase, all three instances of the pricing aggregator 610 share the samecustomer data source 144, the same cart contents database 146, and thesame pricing data engine 620. The product catalog programming 120 is notshown in FIG. 8 to simplify the Figure. To increase the efficiencies ofthe caching, the multiple instances of the pricing aggregators 610 sharecache-1 612, cache-2 614, and cache-3 616. These caches 612, 614, 616may be, for instance, level 2 cache that exists outside the processingcores that operate the pricing aggregators 610. Because this cache 612,614, 616 in not inside any of the processors, each instance 610 canshare the data found in these shared, external caches 612, 614, 616,even if that instance 610 was not responsible for the original datarequest that placed the data within those caches 612, 614, 616.

The many features and advantages of the invention are apparent from theabove description. Numerous modifications and variations will readilyoccur to those skilled in the art. Since such modifications arepossible, the invention is not to be limited to the exact constructionand operation illustrated and described. Rather, the present inventionshould be limited only by the following claims.

What is claimed is_(:)
 1. A system comprising: a) a computer processor;b) data communication to a customer data source, a cart contents datasource, and a pricing data engine; c) a first data cache, a second datacache, and a third data cache; d) programming operating on the computerprocessing device, the programming operating the processor to: i)receive a product price request comprising a product identifieridentifying a product, and a user identifier; ii) request customerinformation for the user identifier from the customer data source; iii)receive customer information from the customer data source; iv) storethe customer information in the first data cache to allow for laterretrieval of the customer information without the involvement of thecustomer data source; v) request cart content data for the useridentifier from a cart contents data source; vi) receive user-specificcart content from the cart content data source, the user-specific cartcontent comprising a plurality of cart product identifiers indicatingproducts in an electronic shopping cart related to the user identifier;vii) store user-specific cart content in the second data cache to allowfor later retrieval of the user-specific cart content without theinvolvement of the cart content data source; viii) request pricing datafor the product identifier and for the cart product identifiers from thepricing data engine; ix) receive pricing data from the pricing dataengine, the pricing data comprising a plurality of prices for theproduct identifier, with a discounted price in the pricing data beingassociated with a trigger condition, the pricing data further comprisingprices for the cart product identifiers including a bundled discountrequiring the purchase of the product; x) store the pricing data in thesecond data cache to allow for later retrieval of the pricing datawithout the involvement of the pricing data engine; xi) determine that aprice for the product based on whether the customer information meetsthe trigger condition; and xii) transmit the price and the bundleddiscount in response to the product price request.